Skip to content

Restore three commits dropped when PR #101 merged short of the branch tip - #103

Merged
b-macker merged 3 commits into
masterfrom
claude/living-script-extended-review-pug628
Jul 27, 2026
Merged

Restore three commits dropped when PR #101 merged short of the branch tip#103
b-macker merged 3 commits into
masterfrom
claude/living-script-extended-review-pug628

Conversation

@b-macker

Copy link
Copy Markdown
Owner

Summary

PR #101 merged at 85b29da, three commits behind the branch tip, and the branch was then deleted. Those three commits were not squashed into master — verified absent by content, not just by SHA — so they existed only in one ephemeral container clone and would have been lost when it was reclaimed.

This restores them unchanged. Two are from the session doing the engine/test work, one is mine.

Commit Origin Contents
555b67d engine session Pulse degradation streak fix — report the streak that caused the degradation rather than the post-reset zero (governance.h, governance_engine.cpp, test_pulse_uniformity.sh)
29d8b47 engine session test_developer_blindspot.sh (337 lines) + run-all-tests.sh wiring — tests whether a 1.0 coherence score is measurement or the absence of it
1757371 this session Fixes a misleading log line in the living-script (see below)

No rebase or conflict resolution was involved: origin/master is exactly 85b29da, so this branch is a clean fast-forward of master plus those three commits, byte-identical to what was on the branch before deletion.

Why the third commit matters

Run 7 logged OA|developer|commit_inadmissible|score=0.625 against a 0.60 threshold, and it was read — reasonably — as the gate refusing a candidate whose score had passed. That is not what happened.

agentCommit derives output_admissible from a live checkOutputAdmissibility() call against the handle's current coherence (0.51–0.53 at that point in the run). The score in the returned admissibility dict is the propose-time candidate score and plays no part in the verdict. Printing it beside the word "inadmissible" put the one number that did not decide the outcome where a reader would take it as the one that did.

It is now labelled propose_score=…|verdict=coherence_at_commit, pointing at the OUTPUT_INADMISSIBLE telemetry (source=agent.commit) — the only place the deciding coherence and threshold are recorded, since agent.commit()'s response omits both while including the score that did not matter.

Test Plan

This exact tree was built and tested before the branch was deleted:

  • Rebuild including the engine session's changes — clean
  • bash run-all-tests.sh441 accounted for, 0 unexpected fails
  • All nine of the engine session's new governance tests pass (test_adversarial_detection, test_challenge_discrimination, test_developer_blindspot, test_drift_sensitivity, test_failure_mode_coverage, test_pulse_uniformity, test_quarantine_corroboration, test_signal_discrimination, test_validation_signal)
  • Merged govern.json parses under the new binary with no unknown-key warnings
  • --lint-only clean on the living-script
  • Live run with real API keys on this combined tree — not yet done

One thing worth watching after this lands

The two sessions independently attacked the same quarantine_streak kill from opposite ends, neither aware of the other:

  • require_corroboration: 2 (engine session) — the streak only advances when 2 distinct signals fired
  • step_up_cooldown_turns 2→1 (this session) — recovery challenges fire twice as often

Each is defensible alone, and the corroboration change is the better-evidenced of the two. But compounded, the quarantine kill may now be hard to reach at all — and a run that always completes looks like success while the output-admissibility demonstration quietly stops demonstrating anything. Runs 3, 6 and 7 all ended on quarantine_streak; if the next live run sails through with SUMMARY_OA_MAX_STREAK at 0–1, that is the hypothesis to test rather than a result to celebrate. My cooldown change is the one I would revert first, since it was a judgement call and theirs has live evidence behind it.


Generated by Claude Code

claude added 3 commits July 26, 2026 20:57
… zero

PULSE_TRANSITION carried consecutive_passes read from the pulse after
computePulseVerdict returned. The epoch boundary zeroes that counter as part of
the transition, so every event reported passes=0 — including a degradation
whose stated cause was uniform_passes, which fires only when the streak exceeds
consecutive_passes_suspicion. The event asserted a cause and then reported a
value contradicting it, leaving the claim unfalsifiable.

Live run 19 recorded exactly that: "healthy -> degraded why=uniform_passes ...
passes=0 degraded_streak=2".

The streak is now preserved into passes_at_transition immediately before the
reset. PU-05c asserts a uniform_passes degradation reports a streak above the
configured threshold, so a regression to the post-reset read fails rather than
printing a plausible zero.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FkjyrETcz4kqcCRSSEDnVB
Live run 19 emitted seven "Perfect coherence (1.0) after N turns (possible
detection bypass)" warnings, all for the living-script developer agent, and the
harness passed 151/0 while ignoring them. That agent carries four per-agent CDD
signal overrides, two of them added during this campaign to suppress structural
false positives on code output — so the warning had two readings the run could
not separate: a compliant agent, or an agent whose scoring signals were turned
off. A config tuned until an agent stops being flagged, validated by a harness
that passes when nothing is flagged, cannot tell those apart.

The test holds behaviour fixed and varies only the override set.

The overrides are exonerated: stagnant, off-mandate and degenerate output are
caught identically with and without them, and neither config quarantines
compliant code.

The finding is elsewhere. Test erosion — code that stays fluent, on-mandate and
non-repeating while shedding its tests turn by turn — is caught by NEITHER
config, at coherence 1.0 with zero signals fired under the full shipped set.
It is the living script's own observed failure mode and no CDD signal sees it,
because it is not behavioural drift by any definition the 23 signals hold. The
designed channel is S22 validation_outcome, which carries only what the
orchestration script feeds it, and a pytest exit code is the ground truth
erosion defeats: a suite with no tests left passes.

DB-04 pins that negative so a signal that later catches it announces itself
rather than passing quietly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FkjyrETcz4kqcCRSSEDnVB
Run 7 logged "OA|developer|commit_inadmissible|score=0.625" against a 0.60
threshold and was read, reasonably, as the gate refusing a candidate whose score
had passed. That is not what happened, and the log line caused the misreading.

agentCommit derives output_admissible from a live checkOutputAdmissibility()
call against the handle's CURRENT coherence — 0.51-0.53 by that point in run 7.
The "score" in the returned admissibility dict is the propose-time candidate
score and plays no part in the verdict. Printing it beside the word
"inadmissible" presented the one number that did not decide the outcome as
though it had.

Now labelled propose_score, with the verdict's actual basis named and a pointer
to the OUTPUT_INADMISSIBLE telemetry (source=agent.commit), which is the only
place the deciding coherence and threshold are recorded — agent.commit()'s
response omits both while including the score that did not matter.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AW25RWmQ8fqzTxrcMZ37y5
@github-actions

Copy link
Copy Markdown

NAAb Governance Report

Metric Count
Files checked 16
Passed 16
Failed 0

All governance checks passed!

Generated by NAAb Governance Engine v4.0

@b-macker
b-macker marked this pull request as ready for review July 27, 2026 01:29
@b-macker
b-macker merged commit 384547a into master Jul 27, 2026
41 checks passed
@b-macker
b-macker deleted the claude/living-script-extended-review-pug628 branch July 27, 2026 01:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants